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(54) Title: DEVICE INTEROPERABILITY 
(57) Abstract 

A device having means for controlling operating modes 
of the device processes control and query data received from 
the second and third electronic devices for managing the 
communication relationships amongst these devices. The 
invention involves a system for communicating between 
multiple electronic devices, such as consumer electronic 
devices or the like, via interconnections such as digital data 
buses. 
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DEVICE INTEROPERABILITY 

Field of the Invention 

5 The invention involves a system for communicating between 

multiple electronic devices, such as consumer electronic devices or 
the like, via interconnections such as digital data buses. More 
particularly, this invention concerns an arrangement for managing 
the interoperability of such devices. 

1 0 

Background of the Invention 

A data bus can be utilized for interconnecting electronic devices 
such as television receivers, display devices, video-cassette recorders 

1 5 (VCR), direct broadcast satellite (DBS) receivers, and home control 

devices (e.g., a security system or a temperature control device). 
Communication using a data bus occurs in accordance with a bus 
protocol. Examples of bus protocols include the Consumer Electronics 
Bus, or CEBus, and the IEEE 1394 High Performance Serial Bus. 

20 

A bus protocol typically provides for communicating both 
control information and data. For example, CEBus control information 
is communicated on a "control channel" having a protocol defined in 
Electronics Industries Association (EIA) specification IS-60. Control 

2 5 information for a particular application can be defined using a form 

of programming language known as CAL (Common Application 
Language). 

Consumer electronics devices are becoming increasingly 

3 0 complex and provide an ever-increasing number of features. While 

coupling these complex devices together via a data bus may be 
necessary to provide a complete audio-video (A/V) system, doing so 
creates numerous problems. For example, certain features of one 
device may require interaction with one or more devices coupled to 
3 5 the bus. A capability of one device may be needed to complete a 
particular operation in another device. Conflicts between the needs 
of various devices may occur. 



BNS0OCI0: <WO Q817033A1 J_> 



WO 98/17033 PCT/US97/18750 

2 

At present, when more that one device competes for the use of 
a common resource, for example a third device connected on the 
network bus, the- first in time controls the device. The other device 
cannot gain access to the common resource until the first device 
5 releases its hold . the resource. This does not pose a problem in 
simple netwoi.,, for example a network comprised of a television a 
cable box, and a VCR. In such simple networks the VCR is 
"controlled" by the cable box, that is the VCR will only record what 
the cable box is providing. However, in more complex networks two 
1 0 devices, for example a cable box and a digital broadcast receiver, 
may compete for control of a shared resource, i.e., a VCR. 

Summary Of The. r P v^r^ v 

1 5 In many control applications it is desirable to discriminate 

against general access to a device. This discrimination usually 
benefits a single device. In such a case, a special relationship called 
"locking" develops, for either a short or long duration of time, 
between two devices. The locking relationship allows one device to 

2 0 control the access to a second device (i.e., a "locked device"). 

In general there are two types of locking approaches. In the 
first approach, the locked device determines if it can be unlocked 
and/or locked to another device. A request to lock the device is 

2 5 made directly to the locked device. If the locked device cannot 

satisfy the new request, the locked device polls the device which 
locked it (i.e., the locking device) to ascertain whether or not the 
existing lock can be terminated and a new lock be consummated. If 
the locking device does not respond, for example, in the event of a 

3 0 failure, the locked device terminates the lock and establishes the new 

lock. In the second approach, a device wishing to lock another device 
broadcasts a request over the network that any device having a lock 
on the desired device terminate its lock. 



35 



Generally, in accordance with the invention, a first electronic 
device comprises means for coupling to a data bus and control means 
for controlling communication via the data bus between the first 
electronic device and second and third electronic devices coupled to 
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the data bus. The control means processes control and query data 
received from the second and third electronic devices for managing 
the communication relationships amongst these devices. 



5 In accordance with one aspect of the present invention there is 

provided a device having a means for communicating with at least a 
second device interconnected by a network bus, thereby creating a 
relationship between said first mentioned device and said second 
device, said communication means being capable of receiving query 
1 0 data from a third device. Further, the device has a first means for 
storing information pertaining to the persistence of said relationship 
and a second means for storing information pertaining to a condition 
for terminating said relationship, and a means for controlling 
operating modes of said device in response to control data from said 

1 5 second device. The controlling means is capable of processing said 

relationship information and said query data and of terminating said 
relationship in response to one of said terminating condition and said 
query data. 

2 0 In accordance with another aspect of the present invention the 

relationship information comprises one of a first state wherein said 
relationship is terminated in response to said query data and a 
second state wherein said relationship is maintained regardless of 
said query data. 
25 - 

In accordance with yet another aspect of the present invention 
the termination of said relationship in response to said query data 
comprises forming a new relationship between said consumer 
electronic device and said third device. 

30 

In accordance with still another aspect of the present invention 
the controlling means is capable of polling said second device, in 
response to the receipt of said query data to obtain permission to 
terminate said relationship. 

35 

In accordance with still another aspect of the present invention 
there is provided a system having a plurality of devices 
interconnected to one another by a network bus. Each device having 
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a means for communicating, first and second means for storm* 
information and a means for controlling the operating modes o°f said 
device as described hereinabove. 

5 In accordance with a method aspect of the present invention a 

consumer electronic device connected on a network bus, the method 
comprises communicating with at least a second device 
interconnected by a network bus, controlling operating modes of said 
consumer electronic device, storing information pertaining to a 
1 0 persistence of said relationship and a predetermined condition 

pertaining to a condition for terminating said relationship, receiving 
query data from a third device, processing said information 
pertaining to said significance of said relationship and said query 
data, and terminating said relationship in response to one of said 
i 3 terminating condition and said query data. 

Brief Descriotion Of Ty Drawing 

?n , ^ inVenti0n ^ be better understood by referring to the 

enclosed drawing in which: 

Figure 1A shows, in block-diagram form, a system of electronic 
devices coupled together using a data bus; 

2 5 Figure IB shows, in block-diagram form, further detail of a 

portion of the system shown in Figure 1A; and 

Figures 2 through 7 show flow diagrams illustrating the 
operation of the system shown in Figure 1 

30 

In the drawing, reference numerals that are identical in 
different figures indicate features that are the same or similar. 

j5 Detailed Description nf t he Drawing 

Figure I A shows a system including three electronic devices A 
and C ' lde ntified by reference numerals 110, 100 and ir- 
respectively, that are coupled together via data bus 130 Devices A 
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B, and C may be various types of electronic devices including 
consumer electronic devices such as audio and/or video signal 
processing devices and home control devices. Specific examples of 
consumer electronics devices include television (TV) receiver, display 
5 devices, cable boxes, video tape recorder (VTR or VCR), direct 
broadcast satellite receivers (such as a DSS satellite receiver), 
compact disc (CD) units, digital video disc (DVD) units. Home control 
devices include security devices (e.g., cameras, locks), remotely 
controlled switching devices, and environment control devices (e.g., 
1 0 heating, cooling). A system incorporating principles of the invention 
may include more than the three devices shown in Figure 1A. Also, 
each device may be a different type of device. For example, a system 
in accordance with the invention might include numerous devices 
throughout a home including TV, VCR, cable box, satellite receiver, 

1 5 audio system, and home control devices. 

In the example shown in Figure 1A, data bus 130 includes 
multiple signal paths for communicating data and control information 
between the devices. The bus structure may be serial or parallel. 

2 0 Data communication on the bus may be in accordance with any one of 

a variety of bus protocols such as the CEBus or IEEE 1394 protocols 
identified above. Data communicated via bus 130 can include video 
and audio data. For example, a satellite receiver receiving a digital 
video signal could transfer digital video and audio data via bus 130 

2 5 to a digital tape recorder (DTR) for recording. 

Device 100 includes bus interface unit 102 for coupling device 
100 to bus 130. Bus interface 102 includes hardware suitable for 
receiving data from bus 130 and for transmitting data on bus 130. 

3 0 For example, interface 102 may include registers or buffer memory 

for receiving and temporarily storing data from bus 130 until device 
100 is ready to process the data, and for storing data until ready for 
transmission on bus 130. 

3 5 Interface 102 is controlled by control microcomputer (p.C) 104. 

The term "microcomputer" is intended to represent various devices 
including, but not limited to, devices such as microprocessors, 
microcomputers, controllers, and control computers that are 
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implemented using one or more integrated circuits and/or discrete 
components. Microcomputer 104 controls the passing of data 
between interface 102 and other units within device 100 such as 
signal processing units (not shown in Figure 1A). For example if 
5 device 100 is a DTR and bus interface unit 102 is receiving digital 
video data for recording, u.C 104 ensures that interface 102 passes 
video and audio data to signal processing circuitry within device 100 
such that recording occurs as intended. Also, jiC 104 controls 
interface 102 so that interface 102 communicates data to and from 
1 0 bus 130 in accordance with the appropriate bus protocol. 

Microcomputer 104 implements the desired bus protocol under 
control of a control program and data stored in memory 106. 
Memory 106 may include various types of memory including RAM, 
I 5 ROM, EEPROM, and hard drive or other types of bulk storage devices. 
The control program may include routines for controlling functions of 
bus interface 102 such as enabling or disabling communication, 
coordinating bus operations with other operations within device 100, 
and formatting data for bus communication 

20 

One aspect of controlling bus interface 102 that is provided by 
[iC 104 is determining how to resolve conflicting requests for use of 
resources within device 100. For example, consider the situation in 
which device 110 is a cable box, device 120 is a DSS satellite receiver 
2 5 and unit 100 is a video tape recorder (VTR). A user may program 

VTR 100 to begin recording a particular program via cable box 110 at 
a particular time. A conflicting command causes DSS unit 120 to 
attempt to access VTR 100 while it is recording the program via cable 
box 110. Conventional systems resolve the described problem by 
either ignoring the attempted access by DSS unit 120 or by notifying 
the user that VTR 100 is unavailable. 



30 



In accordance with an aspect of the invention, the system 
shown in Figure 1A implements a lock manager for resolving 
3 5 resource conflicts in a manner described in detail below. In the 

exemplary embodiment shown in Figure 1A, U.C 104 operates under 
control of a "lock manager" routine included within the bus control 
program to insure that device 100 resolves conflicts in a manner 
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described in detail below. A "lock mechanism" 1070 routine is also 
be included within the bus control program; the operation of lock 
mechanism 1070 is described in the detailed description of Figure 2 
below. The lock manager provides for establishing communication 
5 relationships, or locking conditions, between devices coupled to bus 
130 and for determining under what conditions these relationships 
are modified. Operation of the lock manager involves parameters 
that are stored in a portion 107 of memory 106 and will be described 
in more detail below. Parameters associated with a lock relationship 

1 0 that are involved in resolving a conflict are stored within the lock 

manager region 107 of memory 106 in Figure 1A. Three such 
parameters are persistence, locked address, and unlock condition. 
Figure IB illustrates these three parameters being stored as three 
separate entries 1071, 1072, and 1073 in memory region 107. It 
15 should be noted that, although not shown in Figure 1A, devices 110 
u nd 120 each include features that provide functionality similar to 
that described herein as being provided by units 102, 104, 106 and 
107 within unit 100. The structure within units 110 and 120 may be 
similar to that shown within device 100, but similar functionality 

2 0 could be produced using other arrangements also. 

As an example of the operation of the lock manager, consider 
the conflict example described above. Using the lock manager, 
recording a program from cable box 110 using VTR 100 involves the 

2 5 bus control capability of cable box 110 transmitting a lock request to 

VTR 100. The lock request asks VTR 100 to establish a relationship, 
i.e., to establish a locked condition, with cable box 110. 
Microcomputer 104 receives the lock request via bus interface unit 
102 and determines whether or not VTR 100 is already locked to 

3 0 another device. If not, i.e., the VTR is available for locking, VTR 100 

sends a reply to cable box 110 indicating that the lock has been 
established in lock mechanism 1070. Recording of the desired 
program from cable box 110 proceeds and the lock relationship 
prevents interruption of the recording except under certain 
3 5 conditions that are defined by parameters such as persistence and 

unlock condition described above and, in more detail, below, that are 
associated with the lock relationship. The value of these parameters 
is established by the locking device, i.e., the unit initiating the lock 
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ondiion (cable box 110 i„ the present example) and are transferred 
o and stored In the locked dev lce (the VTR in the present example 
^respective portions of region 107 of memory 106. When DSS un t 

5 20 lendT , US l ° f 10 °' iOCk man3ger ^ DSS unit 

^ 120 sends a lock request to VTR 100. Because a pre-existing lock 

relationship exists between VTR 100 and cable box 110, the lock 

manager within VTR 100 processes the lock request from DSS 120 m 

rVTRToo Wit V he T™ ° f £XiSting ,OCk COndition -red 
10 descried bell ^ ^ ^ '» ** " 

1070 F i g T 2 niUStrateS ° Perati ° n ° f the lockin S mechanism 
1070 which cooperates with lock manager 107. Lock manager 107 

manages the relationships or locks that a -master device" initiates 

Lock mechanism 1070 carries out the locking of the two devices ' 

together. When a master device desires to initiate a lock it sends a 

command to the slave device. A device may be in any one of various 

states mvolving lock control. Four such states, unlocked, locked 

unlock request pending, and change lock pointer, are illustrated' by 

ovals 210, 220, 230 and 240 in Figure 2. Transitions between the 

states are illustrated by lines connecting the ovals. As shown at the 

top of Figure 2, a lock manager can receive requests including lock 

and unlock requests. As shown at the bottom of Figure 2 a lock 

mechanism can produce responses such as "grant.lock" or 

2 5 "lock_in_use" in response to requests. Also, a lock mechanism 

produce an unlock request and a device error/reset indication. 

«.r £n '"TV 11 FigUrC 2 ' the SyStem tran ^tions from unlocked 
state 210 to locked state 220 in response to a lock request and issues 

!J F " k r6SPOnSe - A return to unlocked state 210 from locked 
state 220 occurs in response to a lock being released. Lock release 
occurs by transitions through states 230 and 240. In response to an 
unlock request, the system moves , from state 220 to unlock request 
pending state 230. At state 230, the system processes parameters 
3 5 such as the persistence parameter and the unlock condition to 

determine whether a lock should be released. If the lock witf not be 
dissolved, a lock_in_use message is sent and the system returns to 
locked state 220. If the lock can be dissolved, an unlock messaee is 



can 
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issued and the system transitions to state 240 in which the locked 
address, or locking pointer, is changed to that of the device now 
requesting a lock. Subsequently, the system transitions to locked 
state 220 and issues a grant_lock message. 

The operation of the lock manager 107 and lock mechanism 
1070 under various conditions, i.e., during various types of 
transactions between devices, is illustrated in Figures 3 through 7. 
In Figure 3, a device B is not locked and, in response to a lock request 
from device A, device B establishes a lock with device A. 

In Figure 4, device B is locked to device C in response to a 
previous lock request and receives a conflicting lock request from 
device A. The persistence parameter is set at 0 meaning that device 
B need not request approval of unlocking from device C prior to 
unlocking and re-locking with device A. Device B must only evaluate 
the unlock condition parameter to determine whether or not to 
dissolve the lock with device C. 

In Figure 5, device B is locked to device C in response to a 
previous lock request from device C and the persistence parameter is 
set to 1. Device B sends an unlock request, also referred to as a 
"disinherit lock" request, to device C. The lock manager in device C . 
determines whether to release the lock or not. In Figure 4, device C 
decides to maintain the lock and sends a "resource in use" message 
that is relayed to device A by device B. 

Figure 6 shows a transaction similar to that in Figure 4 (i.e., 
persistence = 1) except that device C responds to device A's lock 
request by dissolving device Cs lock with device B. Thus, device C 
sends an unlock message to device B and device B subsequently 
grants a lock with device A. 

Figure 7 shows a transaction in which device B is locked to 
device C with the persistence equal to 0 and device A hails all locking 
managers indicating device A's desire to lock with device B. Device C 
notifies device A that device C will release its lock with device B. 
Device A then sends a lock request to device B and, because the 
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persistence parameter is set to 0, device B locks to device A and can 
send a message to device C instructing device C to dissolve the lock 
with device B. 

Further it is within the scope of the present invention that only 
locking or master devices require lock managers 107 and that slave 
or lockable devices only employ lock mechanisms 1070. The 
operation of such a system is similar to the system described herein. 

Further details regarding the lock manager aspect of the 
invention, including features of the lock manager in addition to those 
already described, are described below. For convenience only, the 
following detailed description includes aspects based on utilization of 
the CAL Programming Language; however, it should be noted that 
any suitable alternate programming language may be substituted 
therefor. 

Examples of Applications using Locking 

The following describes application in addition to those already 
described in which a locking relationship is required. In a first 
example, a device ("Device A") desires to download several packets of 
data into a remote device ("Device B"). Device A does not want the 
data placed in Device B to be overwritten until the downloading is 
complete. Normally, this function requires a Segmented Network 
Service in both devices. However, in accordance with this invention, 
Device A sets up a temporary locking relationship that insures it is 
the only device capable of writing to Device B. After the data 
transfer, Device A terminates the locking relationship and, "unlocks," 
Device B. 

In a second example, an external device, such as a cable box, 
executes a program timer event. The cable box "locks" the VCR 
transport mechanism. This keeps the VCR in the record mode until 
the session ends or an override condition occurs. The cable box sends 
a Stop command to the VCR and unlocks the VCR at the end of the 
event. 
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In a third example, a device desires to display an OSD message 
for a period of time. The device locks the display to itself and sends 
the relevant display information. This display device displays the 
information for a period of time. The locked device is unlocked by 1 
5 either the locking device itself or by a conditional event, for example 
a time out. 

A special form of locking, "listening", is also implemented. 
Controlling and inter-operating with various devices requires the 

1 6 ability to know their status. A device that contains listening 

capability discriminates between broadcast reports sent out by a 
particular group of devices, e.g., devices located within a house. 

For example, status change information is automatically sent 
15 from one device to another. A VCR updates its motion mode status, to 
a display device or a temperature sensor sends an update to an 
environmental manager. There are two problems with this 
approach. The first problem is determining where the report should 
go. The companion problem is for the receiving device to determine 

2 0 what reported information is important to its function. This occurs 

when there are multiple instances of the same device type, such as 
thermostats or security sensors, reporting to various sub-systems in 
the same house. There is a need to discriminate between sources of 
information. The listening function accomplishes this function. 

25 

There are various applications of listening. Some are more 
dynamic than others. Environmental control is an example of stable 
(static) listening application. In such a system, the listening functions 
are relatively static after an initial setup function. These systems 

3 0 require a reliable and inexpensive means for listening. Issues such 

as security and special access are important. The system 
configuration occurs at installation and rarely changes with great 
frequency. 



3 5 This is in stark contrast to an A/V system. An A/V system is 

very dynamic. Devices are installed and removed with relative 
frequency. Source of video and request function cause the systems 
configuration to change rapidly and regularly. Playback, Record, 
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Display message, and Timer Events all require changes in the 
listening and locking of device. There is a need to change the 
listening source device from VCR to a DBS device in an instant. There 
is also a great deal of inter-device listening. A TV may be listening 
to one device, an environmental system, for display while a cable box 
is listening to the status of a VCR. 

There are various levels of locking and listening desired. In 
many instances, an application requires only a device level locking. 
However, there are cases when it is desirable to lock at an object 
level. (That is. a device may be comprised of more than one object, 
for example a device may have separate controllable functions within 
the device itself.) Once such situation is a VCR application where it 
could be desirable to lock the transport mechanism while allowing 

1 5 other devices to edit or add timer events. Likewise, although it is 

desirable to lock the display object in a TV to guarantee proper 
display, it is not desirable to lock the devices' ability to respond to 
other communications. 

2 0 The locking attribute has relational, conditional and inherited 

characteristics. An example of a conditional locking characteristic is 
when an object is already locked by a device. The unlocked objects 
are lockable; however, the device may not be lockable. In such a 
situation, the device is lockable only by the same device that locked 
2 5 one of its object. Inherited locking infers that all the objects in a 
device inherit the locked status of the object. 

The Lock Manager 

All devices that desire to lock other devices must have a "Lock 
Manager" which keeps track of all the active locks initiated by the 
device and is responsible for locking and unlocking remote devices. 
A structure of such a lock manager, implemented in CAL is provided 
below. 



3 0 
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Lock Manager 


(16) DataList Memory 




This provides a central clearing house for locks established by 
the device. 
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Context Function 


a (61) 


R 


n 


number_of_locks 


size_of_memory 


b (62) 


R 


n 


Length_of_lock 
.pointer 


length_of_record 


C*(43) 


R/V 


T n 


current lock 


current_index 


I*(6c) 


R/V 


? d 


lock_pointer 


memory_block 



The above delineated parameters are described hereinbelow. 



1 . Lock_Pointer Definition 

Each record of the Data Memory memory_block instance 
5 variable (IV) is a pointer to the locked device, residing remotely on 
the network. The lock_pointer data includes three fields: (1) < 
Device_Network_Address>; (2) <Locked_Context_ID>; and (3) 
<Locked_Object_ID>. Those fields that are left blank are considered as 
null. 

The Device Network Address field is the network address of the 
locked device. In a CEBus application, the MAC address is used as 
the network address. 

1 5 The Locked_Context_ID field contains two bytes. The first byte 

is either a Context number or the context wildcard "DE". The DE 
wild card implies that the lock corresponds to all the instanciations of 
the same context in the device. The second byte is the 
Context_Class_ID. The remaining bytes are null. 
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The Locked_Object_ID field is split into two bytes. The first 
byte is either the Object.Number or the Object wild card "00" When 
the object wild card is used the second byte is the Object.Class 
When the wild card is not used, the second byte is null. This allows 
the locking of all objects within the same Object Class. 

2. Unlock Message Definition 

The locked device sends an unlock message to the Locking 
Manager. There are three defined unlock messages: (1) 
Device.Unlock; (2) Context_Unlock; and (3) Object Unlock. 

The unlock message is sent using a Macro, U4. The U4 macro 
contains two argument fields. The first argument contains the 
Dev 1C e_Network_ Address. The second, argument contains the context 
and object information. The macro prototype is 

"<context_TD> <object_ID> U4 <data token> <size of data> <escape token> 
<Device_Network_Address> F5 xdata token> <size of data> <escape 
token> <Context_NumberxContext_Class_rD><Object_IDxObject_Class>" 

2 0 When a context is locked the Context.Number and 

Context_Class_ID are placed in the second argument field (the 
Object.ID and Object.Class are not supplied). The object information 
is null. 

2 5 When an object is locked, the Context_Number, 

Context_Class_ID, Object.ID and Object_Class are also supplied in the 
second argument. 

a) Device Unlock Message 

The Device_Unlock message must contain the locked device's 
<Device_Network_Address >. The second argument is not contained 
in the message. 

"00 04 55 34 F5 F5 F4 34 F6 <Device_Network_Address>F5 " 



30 
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Examples of Locking Pointing Vectors Placed in the Lock Manger Object 
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Locking Devices 

The ability to lock a device is dependent upon locks previously 
put into place. Device locking requires that all other locks be 
overwritten. 



1 0 



1 5 



The Locking implementation uses the variables (IV) in the 
following table. The Locking.Address IV must be present in all 
implementations. The default level of persistence is "0." The 
following sub-sections contain a detail explanation of the IVs. 



IV 


R/W 


Type 


Name 


B (42) 


R/W 


N 


persistence 


E (45) 


R/W 


D 


Key_Entry 


G* (47) 


R/W 


D 


Locking Address 


O (4F) 


R/W 


D 


Unlock Condition 



a) Persistence IV 

The Persistence IV influences the device's unlock behavior. 
There are presently three defined persistence levels: (0) Loose; (1) 
Tight; and (2) Listening. The persistence IV has a default level of 
Loose. When a device reverts to an unlocked state it should set 
persistence to the default value. 



A loose locking level occurs when the persistence level is "0 " 
Loose locking results in a device discriminating between devices that 
2 0 attempt to control it. However, the binding is loose. This means that 
the locked device may grant the request for a new lock with 
confidence that the previous locking device must dissolve the pre- 
existing lock. When the locking level is loose, the locking device 
should automatically release the lock upon request. This results in 
fast disassociation of previous locks and granting of new locks. 

When a loosely locked device receives a request to change the 
Locking.Address. it returns a completed message and sends a 
notification to the previous locking device to dissolve the lock. Loose 
locking infers any device can change the Locking_Address IV. 

Tight locking occurs when the persistence field is set to "1"; 
this allows only the locking device to change or grant permission to 



2 5 



3 0 
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30 



change the Locking_Address IV. This is useful when a third device 
desires to create a lock with the locked device. In this case, the third 
device queries the locked device. The locked device sends an unlock 
message to the Lock Manager Object of the locking device. The 
locking device can either yield its lock or not yield its lock; that is the 
locking device returns a Completed Token, FE, when it dissolves the 
previous lock. Otherwise, the Locking Manager returns an FD Token 
with error-resource in use (8) code. 

Setting the persistence IV to "2" results in a form of locking 
called listening (as described above). In listening, the "locked" 
device binds itself to another device. A device can implement 
various levels of persistence depending upon its application. 

b) Key.Entry IV 

The Key_Entry IV acts as a simple key into a locked device. 
This IV enables access to protected variables. This option can 
protect private functions, such as special diagnostic and setup 
operations, from general access. It also allows a device to 
discriminate between sources in the Listening application. 

There are two uses of the Key_Entry IV. The first is when a 
tight lock, (persistence = 1), is established. The locking device 
supplies a data type variable Key_Entry value that grants access to 
private areas of the device. This value is defined, for purposes of 
explanation, as the "lock_key." 

The second is in a listening application, (persistence = 2). The 
Listening Function uses the Key_Entry IV as an additional 
discriminator. An explanation of this Key_Entry function occurs later 
in this document. 

In addition to the first level of privacy, a manufacturer can 
choose to make the Key_Entry IV a protected variable that requires 
authentication. This separates the issue of special access and 
authentication. The Key_Entry IV is inactive when a device is 
unlocked or the persistence is not set to "loose". The default 
key_entry value is "null". Whenever a device is unlocked or the 
persistence level is changed, the Key_Entry IV reverts to the default 
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value. This results in only the locking device being able to supply 

or read a Key.Entry IV value. This allows only one device to access 
private data or functions. 

Depending upon the application, the "lock.key" can be a fixed 
key, placed in ROM, or a writeable key, such as a "trusted key " 
Normally there is only one valid Key.Entry value; however there 
can be multiple valid Key.Entry IV values. A manufacturer can 
choose to make the lock_key IV writeable. Protected devices become 
private again by setting the Key_Entry IV to an invalid entry (e g 
logical length is 0) or a false value, by disarming the lock, or 
changing the lock persistence <> 1. 

c) Locking_Address IV 

The Locking. Address IV is a data type variable and is the 
1 5 network address that locked the device. In a CEBus application, the 
MAC address is used as the network address. 

A locking device initiates a lock with a device when it writes its 
network address into the appropriate Locking_Address IV. Once a 
lock is in place setting the Locking.Address IV to an invalid address 
(e.g., logical length is 0) disarms the lock. A lock request to a device 
that does not support locking results in a return Error - Invalid IV. 

d) Unlock_Condition IV 

A third variable is the Unlock_Condition IV which allows a user 
to specify a condition that automatically dissolves a lock. The unlock 
2 5 condition can use IV's found in the device, (this is similar to the 
Event Manager Object). 



20 



30 



35 



The UnIocking_Condition IV contains a Boolean expression that 
defines the unlock condition for the device. The Boolean expression 
is a CAL expression, as defined in the CAL grammar. This program is 
waiting for some condition to occur within the device, such as a timer 
expiration or threshold crossing. The device dissolves the lock upon 
the specified unlock condition. Note that the unlock condition is in 
the locked device. The persistence level can be either loose , or tight. 

A condition is loaded into the Unlock_Condition using the 
setArray method. In this case, the data being loaded is the actual 
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CAL condition program. This program includes the condition to 
watch for that will cause the unlock action. 



Just as in the Event Manager Object, there are two slight 
5 differences in the CAL grammar for the Unlocking_Condition IV to 
operate correctly. The first difference is identifying the instance 
variables to watch. Rather than a simple IV identifier, the context 
and object location of the IV must be supplied. For example, instead 
of testing (current_value > max_value), the Unlocking_Condition 
1 0 would test (Audio Context, Volume Control, current_value > Audio 
Context, Volume Control, max_value). By requiring all bytes, the 
statement can be correctly parsed. 

The Boolean expression contained in Unlock_Condition allows 

1 5 for at most two relations to be evaluated. For example, the Clock 

Object could unlock when hour equals 12 or month equals 6. The 
first IV in the Boolean expression is the value reported. Along with 
the standard relational operators, an additional operator is defined, 
the DELTA operator. Note that when the Unlock_Condition IV is 

2 0 written to (using setArray Method), the object must check the 

validity of the condition being placed in the IV. If the condition is 
invalid, an Error-Bad Argument Type(12) is returned and no 
Unlock_Condition occurs. 

Locking Implementation 

2 5 A device is locked by setting the Locking_Address IV to a 

valid destination address using the setArray method. In the case of a 
CEBus application, the network address is composed of the Unit 
address and House Code appearing in MSB, LSB order. An example of 
a locking message using a Unit Code 0034, House Code 001 A, results 

3 0 in the following message: 

<contextxobject> 46 471 Ff5 Ff5 Ff4 34 Ff6 00 34 00 1A 
(<context><object> setArray GA' <DEL> <DEL> <DATA> 34 <ESCAPE> 
0034 001A) 
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Setting an object Locking_Add ress IV to an invalid address 
(e.g., logical length is 0) unlocks it. 

«context><object> setArray GA' <DEL> <DEL> <DATA> 30 <ESCAPE» 

An Error- Invalid IV is returned when this function is not 
supported. 

1. Object Locking Implementation 

Locking at the Object level is accomplished by setting the 
1 0 locking mechanism in the individual Object. 

2. Context Locking Implementation 

The object level locking is extensible to contexts. Locking at 
the context level is accomplish by setting the locking mechanism in 
the context control Object. 



1 5 



20 



Setting the Locking_Address IV to a valid value locks the 
context. The objects instanciated in the context inherit the same 
Locking_Address. (This only applies when persistence <>2.) If an 
object within the context is already locked, the context cannot be 
locked unless the object Locking.Address IV value is the same as the 
context Locking_Address value. 



The context lock is initiated by writing the network address of 
the locking device into the Context_Locking_Address IV placed in the 

2 5 Context Control Object. 

<context_ID> 01 01 46 47 54 F5 F5 F4 34 F6 <Locking_Address> 

The Context_Persistence, Context_Key_Entry, 

3 0 Context_Locking_ Address, and Context_Unlock_Condition IVs inherit 

their behavior from the Object IVs Persistence, Key.Entry, 
Locking_Address, and Unlock_Condition respectively. 

3. Device Locking Implementation 

Locking at the device level is accomplish by setting the device 
3 5 locking mechanism in the Node Control Object. The Node Control 
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Object can have its own individual Object locking mechanism. The 
device level locking variables are 





Node Control Object (01) Node 

Control 




Variables in Node Control Object that allow for Device Locking 


IV 


R/W 


Type 


Name 


Context Function 


o (6Fh) 


R 


d 


object_list 


list of objects used 
in context 


z (6a) 


R/W 


N 


Device_Persistence 


Persistence 


v (76) 


R/W 


D 


Device_Key_Entry 


Key_Entry 


T* (54) 


R/W 


D 


Device_Locking 
_Address 


Locking_ Address 


V (56) 


R/W 


D 


Device Unlock Condition 


Unlock_Condition 



5 The Device_Persistence, Device_Key_Entry, 

Device_Locking_Address, and Device_Unlock_Condition IVs inherit 
their behavior from the Object IVs Persistence, Key_Entry, 
Locking_Address, and Unlock_Condition respectively. 

1 0 The device lock is initiated by writing the network address of 

the locking device into the Device_Locking_Address IV. 

00 01 46 54 F5 F5 F4 34 F6 <Locking_Address> 
Locking Scenarios 

1 5 For the purposes of demonstration, the locking device is the 

device that desires to lock another device. The locked device is the 
device to be locked. Locking request can be made to either the 
device to be locked or to the lock manager holding the lock. Under 
normal conditions, a locking request is made by attempting to write 

2 0 a new address into the Locking_Address IV. The request can be 

either direct or conditional. 

SUBSTITUTE SHEET (RULE 26) 
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a) Direct Locking Request 

An example of a locking message using a Unit Code 0034 
House Code 001 A, results in the following message: 

<contextxobject> 46 4741 Ff5 Ff5 Ff4 34 Ff6 00 34 00 1A 
(<context><object> setArray 'G' <DEL> <DEL> <DATA> *4' <ESCAPE> I 
001A) 
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The device must determine if it is lockable. If the device 
object, context is not locked a completed token FE is returned The 
locking device places the locking pointer into the lock manger object. 

b) Conditional Object Locking Request 
An example of a locking message using a Unit Code 0034 

House Code 001A, results in the following message: 

<contextxobject> 56 47 F7 <context><object> 46 471 F5f5 Ff5 Ff4 34 
Ff6 00 34 00 1A EB 44 47 F8 

<context><object> I(IF "G " <BEGIN> <context><object> setArray 'G' <DEL> 
<DEL><DATA>'4'<ESCAPE>0034 001A <ELSE> setArray "G" <END> ) 

If the array "G" is not in use the device is locked. Otherwise it 
will not lock the device. This method is used with resource locking 
If the device is in use the requesting device can request "hail" the for 
the locking device to give up the lock, device by sending a broadcast 
message. 

c ) Using LOCK Macro U2 

The LOCK Macro U2 is used to lock context and objects. The 
Macro message contains the Macro ID followed by the arguments list 
3 0 There are two necessary arguments : (1) Locking, Address; and (2) 
persistence. An argument list is considered null if it is not filled. 
After a lock is established, the Key.Entry and Unlock.Condition IVs 
are updated. 



25 



3 5 



<context_ID> <object_ID> "U 2" <data token> <size of data> <escape 
token> <locking_address> F5 <persistence>F5 <Key_Entry> 
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As an example, for the CAL Macro message to lock a context 11: 
"11 Oil 55U 322 F4 34 F6 OF 32 23 34 F5 01 44 

5 

The argument 0Ff32 2334 is the locking address, the 
persistence is set to 1. At this point, the locking device can send 
Entry_Key IV data and a Unlock_Condition IV Data. 

1 0 When the Locking_Address is not supplied it is assumed to be the 

source address of the Macro Message. 

"11 01 55 32 F5 F5 01" 
Locking Release Request 

15 a) Locking Release Request to Locking Master 

(1) using DISINHERIT (option 1) 

If the object is locked, at either the object, context, or device 
level, then it will request that the impeding locks device relinquish 
its lock. The message is sent to the Locking Manger Object: 

20 

< Universal Context > < Locking Manager Object > • disinherit 
<lock_pointer (6C) > F4 [number of bytes] F6 <device_address> 
<context_id> <object> 

2 5 disinherit the lock with <device> <context> <object> 

The context_ID includes the context_number if it is not AO. If it is 
AO, the context number can be optionally included. 

3 0 (2) Using UNLOCK Macro U41 (option 21) 

The UNLOCK Macro U14 is sent to the EVENT Manager Object. 
The macro matches the desired locking pointer and request that it be 
deleted. If a match is present then the locking manager either grants 
the request or denied the request. If the locking device cannot be 
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found, the locked device dissolves the lock. See section 2.1.2 for 
details. 

Listening Implementation 

The listening function is a companion to the reporting method. 
Listening is implemented in objects that are interested in the status 
of other devices or network resources. An example of a network 
resource is time. 



A listening function allows a device to discriminate between 

1 0 broadcast messages containing status information. Listening function 

is a special application of the locking function. In the listening mode, 
the object does not inherit the locking state of the context or device. 
(This is necessary for listening function to perform correctly when a 
device or context is locked). 

15 

In Listening, a device binds itself to another device. This 
means a device can set its own Locking_Address IV. The 
Locking_Address IV is either read only or read/write. The write 
option is actually a type of loose locking. The persistence IV is set to 

2 0 "2." The Key_Entry IV acts as a special access discriminator. The 

following table contains the listening IV list. 





Object Listening IV list 


IV 


R/W 


Type 


Name 


Context Function 


G* (47) 


R/W** 


D 


Locking_Address 


object listening address 


B* (42) 


R 


N 


Persistence 


2 = Listening 


E (45) 


R/W 


D 


Key_Entry 


allows special access 



When the Locking_Address is a read-only variable, the device 

2 5 sets its own locking address When the Locking_Address is set 

externally, the locking device does not place a lock_pointer in its 
Locking Manager. 

There are three different implementations of listening. The 

3 0 first method uses the source network address to gate access to the 

listening object. The object discriminates in favor of the source 
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device address corresponding to the Locking_Address IV. In this 
case, the message is written into the appropriate Instant Variable. 

The second and third listening implementations utilize the 
5 Key_Entry device. This implementation requires macro message. 
The macro message, LI, is used to deliver the Key_Entry value and 
the data simultaneously. The listening device verifies that the macro 
is from the correct source address and that the supplied Key_Entry 
value matches the desired value. 

10 I. Multi-Source Listening Implementations 

There are occasions when a listening object may desire to listen 
to all broadcast sources without discrimination. Once such situation 
occurs when a fire sensors broadcast that it is detecting a fire. It 
broadcast the information onto the network. A listening device 

1 5 wants to listen to all possible sources that would report a fire. 

In a general, the multi-source listening application is 
implemented by allowing a device receive the state of any device 
(sensor). This is denoted by setting the Locking_Address IV to a 

2 0 broadcast address. In a CEBus application, the listening discriminator 

is set to either all Unit_Addresses within a particular House Code or 
to all addresses on the network. The alarm author source or zone 
addresses included in the message; this can be extracted from the 
source_address field or a state vector contained in the message. 

2 5 2. Listening via Key_Entry and Locking_Address 

In this way, the lockjcey value becomes a selector value that 
allows a device to discriminate between individual context and 
objects. For example, in the time context, the time type identifier 
can be supplied in the Macro Message. This value is checked for the 

3 0 desired time type. If a device has multiple instanciations of a 

reporting context, the device can include the context number in the 
Key_Entry field. The receiving node checks the incoming context 
number and verifies it is the one of interest. 

3 5 <context_ID> <object_ID> 53 31 F4 <size of data> <escape token> 5 
<Locking_Address> F5 <data token> <size of data> <escape token> 
<Key_Entry> F5 <Argument_Listmessage> 
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In Listening, a device binds itself to another device. [ n the case 
of listening, a device can set its own Locking. Address IV. The 
Locking_Address IV can be either read only or read/write. 

3. Listening via Key_Entry 

Listening can also be accomplished by setting the 
Locking_Address to "00 00 00 00." In this case the only 
discriminator is the Key.Entry value. This allows an object to 
discriminate based on an access key. This is done as : follows: 

<context_ID> <object_ID> 53 31 F5 00 00 00 00 F5 <data token> <size 
of data> <escape token> <Key_Entry> F5 <Argument_List> 

When the Locking, Address is read only, the device exclusively 
sets its own locking address. When a Locking.Addresss IV is R/W 
the locking is loose. The locking device does not place a 
locking_pointer in its Locking Manager. 

<context_ID> <object_ID> LI <data token> <size of data> <escape token> 
2 0 <Locking_Address > F5 F5<message> 

There are some instances where a unique identifier is desired 
to allow discrimination between multiple context or objects in a 
single device. One example is a temperature sensor device that 

2 5 contains multiple sensors. It may be desirable to bind each sensor to 

a corresponding listening object. This is accomplished using the 
key_entry approach where if key_entry = null there is no 
discrimination. When Key_Entry is set to a value, the listening device 
requires the proper Key.Entry value before it will update the object. 

Example: Listening variable has a discriminator, like the key.entry 
number, which allows the user to set a discriminator. The data and 
discriminator are sent at Macro_ID key_entry F5 Listening DATA. If 
the Key_entry is not supplied, the discriminator is the network 

3 5 address. 
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While the invention has been described in detail with 
respect to numerous embodiments thereof, it will be apparent that 
upon a reading and understanding of the foregoing, numerous 
alterations to the described embodiment will occur to those skilled 
5 in the art and it is intended to include such alterations within the 
scope of the appended claims. 
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Claims 

I. A device comprising: 
5 (a) means for communicating with at least a second device 

interconnected by a network bus. thereby creating a relationship 
between said first mentioned device and said second device, said 
communication means being capable of receiving query data from a 
third device; 

1 0 

(b) first means for storing information pertaining to the 
persistence of said relationship; 

(c) second means for storing information pertaining to a 

1 5 condition for terminating said relationship; 

(d) means for controlling operating modes of said device in 
response to control data from said second device, said controlling 
means being capable of processing said relationship information and 

2 0 said query data and of terminating said relationship in response to 

one of said terminating condition and said query data. 

2. The consumer electronic device recited in Claim 1 wherein said 
relationship information comprises one of a first state wherein said 

2 5 relationship is terminated in response to said query data and a 

second state wherein said relationship is maintained regardless of 
said query data. 

3. The consumer electronic device recited in Claim 2 wherein 

3 0 terminating said relationship in response to said query data 

comprises forming a new relationship between said consumer 
electronic device and said third device. 

4. The consumer electronic device recited in Claim 3 wherein said 
3 5 controlling means is capable of polling said second device, in 

response to the receipt of said query data to obtain permission to 
terminate said relationship. 
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5. The consumer electronic device recited in Claim 4 wherein said 
controlling means is further capable of monitoring the status of said 
second device. 

5 6. The consumer electronic device recited in Claim 5 wherein said 
controlling means is further capable of enabling said second device to 
alter information contained in said consumer electronic device. 

7. The consumer electronic device recited in Claim 1 wherein said 
1 0 predetermined condition is related to one of said relationship 

between said consumer electronic device and said second device and 
an internal condition of said device. 

8. A device comprising: 

1 5 (a) means for communicating with at least a second device 

interconnected by a network bus, thereby creating a relationship 
between said first mentioned device and said second device, said 
communication means being capable of receiving query data from a 
third device; 

2 0 

(b) first means for storing information pertaining to the 
persistence of said relationship, wherein said relationship 
information comprises one of a first state wherein said relationship is 
terminated in response to said query data and a second state > . * 

2 5 wherein said relationship is maintained regardless of said query 

data; 

(c) second means for storing information pertaining to a 
condition for terminating said relationship; 

30 

(d) means for controlling operating modes of said device in 
response to control data from said second device, said controlling 
means being capable of processing said relationship information and 
said query data and of terminating said relationship in response to 

3 5 one of said terminating condition and said query data. 
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9. A system having a plurality of devices interconnected to one 
another by a network bus, each device comprising: 

(a) means for communicating with at least a second device 
over the network bus, thereby creating a relationship between said 
first mentioned device and said second device, said communication 
means being capable of receiving query data from a third device; 

(b) first means for storing information pertaining to the 
persistence of said relationship, wherein said relationship 
information comprises one of a first state wherein said relationship is 
terminated in response to said query data and a second state 
wherein said relationship is maintained regardless of said query 
data; 

1 5 second means for storing information pertaining to a 

condition for terminating said relationship; 

(d) means for controlling operating modes of said device in 
response to control data from said second device, said controlling 

2 0 means being capable of processing said relationship information and 

said query data and of terminating said relationship in response to 
one of said terminating condition and said query data. 

10. A method for controlling a consumer electronic device 

2 5 connected on a network bus, the method comprising: 

(a) communicating with at least a second device 
interconnected by a network bus thereby creating a relationship 
between said consumer electronic device and said second device; 

30 < b ) controlling operating modes of said consumer electronic 

device, at least one operating mode being controllable by said second 
device on said network bus, thereby creating a relationship between 
said consumer electronic device and said second device; 

3 5 ( c ) storing information pertaining to a persistence of said 

relationship and a predetermined condition pertaining to a condition 
for terminating said relationship; 
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(d) receiving query data from a third device; 

(e) processing said information pertaining to said significance 
of said relationship and said query data; and 

(f) terminating said relationship in response to one of said 
terminating condition and said query data. 

11. The method recited in Claim 10 wherein the step of terminating 
further comprises creating a new relationship between said 
consumer electronic device and said third device. 

12. The method recited in Claim 11 further comprising the step of 
polling said second device to obtain permission to terminate said 
relationship. 

13. The method recited in claim 12 further comprising the step of 
monitoring the status of said second device. 

14. The method recited in Claim 13 further comprising the step of 
enabling said second device to alter information contained in said 
consumer electronic device. 
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